Kubernetes - Core Concepts and Usage

Posted: 2026-04-24 Tags: cs k8s

contents

쿠버네티스의 기본 컨셉과 오토 스케일링 테스트, 그리고 주로 간단한 프로젝트 용에 사용되는 미니쿠버에 대해서 알아보겠습니다.

Kubernetes(단어의 'K'와 's' 사이에 8개의 알파벳이 있어 흔히 K8s로 줄여서 부름)는 처음에 배우기 어렵기로 유명합니다. 처음에는 오르기 힘든 거대한 산처럼 느껴질 수 있지만, 핵심 철학을 이해하고 나면 이 시스템이 얼마나 논리적이고 강력한지 깨닫게 될 것입니다.

가장 간단히 말해, Kubernetes는 컨테이너 오케스트레이션(Container Orchestration) 플랫폼입니다. Docker와 같은 도구가 애플리케이션을 실행 가능한 깔끔한 상자(컨테이너)로 포장하는 역할을 한다면, Kubernetes는 그 상자들을 어디에 배치할지, 몇 개의 상자를 유지할지, 상자가 망가졌을 때 어떻게 조치할지를 결정하는 물류 창고 관리자라고 할 수 있습니다.

Kubernetes의 작동 방식, 아키텍처, 그리고 처음 사용하는 방법에 대한 자세한 설명은 다음과 같습니다.

1. 작동 방식: 선언적 모델 (Declarative Model)

Kubernetes를 이해할 때 가장 중요한 개념은 "조정 루프(reconciliation loop)"를 통해 선언적 모델로 작동한다는 점입니다.

기존의 IT 환경에서는 작업을 어떻게 처리할지 스크립트를 작성합니다(예: "서버 A를 시작하고, B를 설치한 다음, C를 실행해라"). 반면 Kubernetes에서는 여러분이 원하는 최종 상태(Desired State)가 무엇 인지만 선언하면 됩니다(예: "내 웹 애플리케이션 복제본이 항상 3개씩 실행되게 해줘").

Kubernetes는 시스템의 현재 상태(Actual State) 와 사용자가 원하는 상태(Desired State) 를 지속적으로 비교합니다. 만약 웹 앱 복제본 중 하나가 다운되어 현재 상태가 2개가 되면, Kubernetes는 즉시 이 불일치를 감지하고 새로운 복제본을 생성하여 다시 3개로 맞춥니다.

2. 아키텍처: 컨트롤 플레인 vs 워커 노드

Kubernetes 환경을 클러스터(Cluster) 라고 부릅니다. 이 클러스터는 크게 두 가지 영역인 컨트롤 플레인(두뇌 역할)과 워커 노드(실제 작업을 수행하는 역할)로 나뉩니다.

컨트롤 플레인 (Control Plane - 두뇌 역할)

클러스터 전체를 관리하는 프로세스들의 집합입니다.

kube-apiserver: Kubernetes의 정문(관문)입니다. 사용자가 명령어를 입력하든 다른 시스템이 K8s와 상호작용하든, 모든 것은 이 API 서버를 거쳐야 합니다.
etcd: 클러스터의 데이터베이스입니다. 매우 신뢰성이 높은 키-값(key-value) 저장소로, 클러스터 전체의 "원하는 상태"와 설정 정보를 기록합니다. 클러스터에 장애가 발생했을 때 이를 복구하는 데 사용되는 핵심 데이터입니다.
kube-scheduler: 작업 분배기(디스패처)입니다. 새로운 애플리케이션의 실행을 요청하면, 스케줄러는 모든 서버 노드의 사용 가능한 CPU와 메모리를 확인하고 해당 앱을 실행하기에 가장 적합한 노드를 결정합니다.
kube-controller-manager: 감독관입니다. 앞서 언급한 백그라운드 "조정 루프"를 실행하며, 원하는 상태와 현재 상태 사이의 불일치를 끊임없이 수정합니다.

워커 노드 (Worker Nodes - 작업자 역할)

애플리케이션이 실제로 실행되는 서버(가상 머신 또는 물리적 서버)입니다.

kubelet: 노드의 선장입니다. API 서버로부터 명령을 받아 자신의 노드에 할당된 컨테이너들이 정상적으로 실행되고 건강한 상태인지 확인하는 에이전트입니다.
kube-proxy: 네트워크 라우터입니다. 노드의 네트워크 규칙을 관리하여 서로 다른 애플리케이션이 통신할 수 있게 하고, 외부 트래픽이 애플리케이션에 도달할 수 있도록 합니다.
컨테이너 런타임 (Container Runtime): 컨테이너를 실제로 실행하는 소프트웨어입니다(예: containerd, CRI-O 등).

3. 핵심 용어: Kubernetes 주요 객체(Objects)

Kubernetes를 사용하려면 다양한 "객체"를 정의하는 YAML 파일을 작성하게 됩니다. 가장 기본이 되는 세 가지 객체는 다음과 같습니다.

Pod (파드): Kubernetes에서 배포할 수 있는 가장 작은 단위입니다. Kubernetes는 컨테이너를 직접 실행하지 않고 Pod라는 껍데기로 감쌉니다. 하나의 Pod에는 보통 하나의 컨테이너(예: 웹 앱)가 들어가지만, 자원을 공유해야 하는 밀접하게 연결된 여러 개의 컨테이너가 들어갈 수도 있습니다.
Deployment (디플로이먼트): 사용자가 직접 Pod를 생성하는 경우는 드뭅니다. 대신 Deployment를 생성합니다. Deployment는 K8s에게 동일한 Pod의 복제본(replica)을 몇 개 유지할지 알려주며, 애플리케이션을 중단 없이 안전하게 업데이트(롤링 업데이트)하는 방법을 제공합니다.
Service (서비스): Pod는 영구적이지 않습니다. 죽고 다시 생성되며 IP 주소도 끊임없이 바뀝니다. Service는 Pod 그룹에 안정적이고 영구적인 IP 주소와 로드 밸런서를 제공하는 역할을 합니다. 백엔드의 Pod들이 계속 바뀌더라도, 사용자의 트래픽이 Service를 향하면 항상 올바른 Pod로 연결됩니다.

4. 처음 시작하는 방법 (Getting Started)

K8s를 배우기 위해 거대한 클라우드 인프라가 필요한 것은 아닙니다. 여러분의 노트북에서도 미니 클러스터를 실행할 수 있습니다.

1단계: 도구 준비하기

로컬 클러스터 설치: Minikube, Kind (Kubernetes in Docker)를 다운로드하거나 Docker Desktop에 내장된 Kubernetes 기능을 사용하세요. 내 컴퓨터에 가상의 K8s 클러스터를 만들어 줍니다.
kubectl 설치: 클러스터의 API 서버와 통신하기 위해 사용하는 명령줄(CLI) 도구입니다.

2단계: 클러스터 시작하기

Minikube를 사용한다면 터미널을 열고 다음 명령어를 입력합니다.

minikube start

3단계: 첫 YAML 작성하기 (원하는 상태 정의)

hello-world.yaml이라는 파일을 생성하고, NGINX 웹 서버 2개를 배포(Deployment)하도록 정의합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

4단계: 클러스터에 적용하기

작성한 파일(원하는 상태)을 Kubernetes에 적용하여 현실로 만듭니다.

kubectl apply -f hello-world.yaml

5단계: 결과 확인하기

Kubernetes가 어떤 작업을 수행했는지 확인합니다.

kubectl get pods

NGINX 앱이 두 개 실행 중인 것을 볼 수 있습니다. 만약 강제로 하나를 삭제(kubectl delete pod <파드-이름>)한 뒤 즉시 kubectl get pods를 다시 실행해보면, Kubernetes가 자동으로 빈자리를 채우기 위해 새 복제본을 띄우는 마법 같은 모습을 볼 수 있습니다.

로컬 환경에서 자가 치유(self-healing) 및 자동 확장(auto-scaling) 환경을 직접 구축해 보는 것은 Kubernetes의 "마법"을 경험할 수 있는 가장 좋은 방법입니다. 마치 미치광이 과학자가 된 것처럼, 여러분이 만든 혼돈에 시스템이 어떻게 반응하는지 실시간으로 지켜볼 수 있죠!

이를 위해 Minikube를 사용할 것입니다. 애플리케이션을 배포하고, 자가 치유를 위한 상태 검사(health check)를 설정하며, 트래픽 급증을 처리하기 위해 수평적 파드 자동 확장기(HPA, Horizontal Pod Autoscaler)를 구성해 보겠습니다.

단계별 가이드는 다음과 같습니다.

1단계: 클러스터 실행 및 메트릭 활성화

Kubernetes가 자동 확장을 하려면 앱이 CPU와 메모리를 얼마나 사용하고 있는지 알아야 합니다. 기본적으로 초기 클러스터는 이를 추적하지 않으므로, Metrics Server(메트릭 서버) 를 켜야 합니다.

로컬 클러스터 시작: minikube start
메트릭 서버 애드온 활성화: minikube addons enable metrics-server

2단계: 자가 치유(Auto-Healable) 앱 생성

Kubernetes의 Deployment는 기본적으로 자가 치유 기능이 있습니다. 컨테이너가 충돌(crash)하면 K8s가 이를 재시작합니다. 하지만 앱이 멈추거나 충돌 없이 무한 루프에 빠진다면 어떨까요?

이 문제를 해결하기 위해 Liveness Probe(활성 프로브) 를 사용합니다. 이는 기본적으로 Kubernetes가 몇 초마다 앱의 문을 두드리며 "아직 살아있니?"라고 묻는 것과 같습니다. 앱이 대답하지 않으면, K8s는 무자비하게 해당 컨테이너를 종료시키고 새로운 컨테이너를 띄웁니다.

magic-app.yaml이라는 파일을 만드세요. 스케일링을 테스트할 수 있도록 의도적으로 CPU 부하를 발생시키게 설계된 Kubernetes 공식 커스텀 이미지를 사용할 것입니다:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        # 자동 확장을 위한 핵심: 리소스 요청(requests)을 반드시 정의해야 합니다!
        resources:
          requests:
            cpu: 200m # 200 milli-CPUs (CPU 코어의 20%)
        # 자가 치유를 위한 핵심: Liveness Probe (활성 프로브)
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

작성한 파일을 클러스터에 적용합니다:

kubectl apply -f magic-app.yaml

3단계: 자동 확장(Auto-Scaling) 구성 (HPA)

이제 Kubernetes에게 이 Deployment를 감시하라고 지시할 것입니다. 파드의 평균 CPU 사용량이 50%를 넘어가면, 부하를 처리하기 위해 K8s가 자동으로 (최대 10개까지) 복제본을 더 생성하도록 만듭니다.

다음 명령어를 실행하여 Horizontal Pod Autoscaler를 생성하세요:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

다음 명령어로 자동 확장기의 상태를 확인할 수 있습니다:

kubectl get hpa

(참고: 메트릭 서버가 데이터를 수집하는 1~2분 동안은 <unknown>/50%로 표시될 수 있습니다. 잠시 후 명령어를 다시 실행해 보세요).

4단계: 재밌는 부분 (망가뜨려 보기!)

이제 자동화가 어떻게 작동하는지 볼 차례입니다. 가짜 트래픽으로 애플리케이션을 강타하여 강제로 확장(scale)되도록 만들겠습니다.

두 번째 터미널 창을 열고 다음 명령어를 실행하세요. 이 명령어는 여러분의 앱에 끝없이 요청을 보내는 일만 하는 임시 파드를 생성합니다:

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

이 명령어를 실행 상태로 두세요. 첫 번째 터미널 창으로 돌아가서 자동 확장기가 어떻게 반응하는지 지켜봅니다. 명령어에 -w (watch)를 추가하면 실시간으로 볼 수 있습니다:

HPA가 CPU 급증을 감지하는 것 지켜보기: kubectl get hpa -w (CPU가 0%에서 250% 같은 수치로 급증하고, 복제본(replicas) 수가 증가하기 시작하는 것을 볼 수 있습니다).
터미널을 하나 더 열거나 이전 명령어를 중지하고, 파드들이 생성되는 모습 지켜보기: kubectl get pods -w (엄청난 트래픽 유입을 처리하기 위해 Kubernetes가 여러 개의 새로운 파드를 띄우는 것을 볼 수 있습니다).

(해당 터미널에서 Ctrl+C를 눌러) load-generator를 중지하면 CPU 부하가 다시 0%로 떨어집니다. 약 5분 정도 기다리면, Kubernetes는 트래픽 급증이 끝났음을 깨닫고 리소스를 절약하기 위해 앱을 다시 정확히 1개의 파드로 우아하게 축소(scale down)시킵니다.

애플리케이션을 실제 웹 브라우저에 띄우는 것은 가장 짜릿한 순간입니다! Kubernetes 세계에서 파드(Pod)는 기본적으로 클러스터의 내부 네트워크에 격리되어 있습니다. 외부 세계에서 접근할 수 있게 하려면 명시적으로 문을 열어주어야 합니다.

우리는 이것을 안전하게 수행하는 데 초점을 맞추고 있고 현재 로컬 클러스터를 실행 중이므로, 아주 훌륭한 두 가지 방법이 있습니다. 바로 "빠른 개발자 터널(Quick Developer Tunnel)"(안전한 로컬 테스트에 완벽함)과 "프로덕션 라우터(Production Router)"(실제 실무 환경에서 사용하는 방법)입니다.

두 가지 모두 자세히 살펴보겠습니다!

방법 1: 빠른 개발자 터널 (포트 포워딩, Port-Forwarding)

개발 중에 안전하게 앱을 확인하기만 하면 된다면 복잡한 네트워킹을 구성할 필요가 없습니다. Kubernetes를 사용하여 로컬 머신의 localhost에서 클러스터 내부의 Service로 직접 연결되는 암호화된 터널을 만들 수 있습니다.

Kubernetes API를 사용해 트래픽을 터널링하기 때문에 태생적으로 안전하며, (공공 카페 Wi-Fi 같은) 더 넓은 로컬 네트워크에 애플리케이션을 노출하지 않습니다.

1단계: 터널 열기

터미널에서 다음 명령어를 실행합니다:

kubectl port-forward svc/php-apache 8080:80

svc/php-apache: K8s에게 "php-apache"라는 이름의 Service를 찾으라고 지시합니다.
8080:80: 로컬 노트북의 8080 포트를 Service의 80 포트와 연결(매핑)합니다.

2단계: 앱 확인하기

웹 브라우저를 열고 다음 주소로 이동합니다: http://localhost:8080

(우리가 사용한 커스텀 hpa-example 이미지의 기본 출력인 "OK!" 메시지가 보일 것입니다).

3단계: 문 닫기

확인을 마쳤다면 터미널에서 Ctrl+C를 누르기만 하면 됩니다. 터널이 닫히고, 앱은 즉시 외부 세계와 다시 완전히 격리됩니다.

방법 2: 프로덕션 방식 (Kubernetes 인그레스, Ingress)

포트 포워딩은 테스트용으로 훌륭하지만, 실제 환경(AWS나 Google Cloud 등)에서는 애플리케이션에 실제 도메인 이름(예: www.myapp.com)을 연결하고 HTTPS/SSL 인증서로 보호하고 싶을 것입니다.

이를 위해 Kubernetes는 Ingress(인그레스) 라는 객체를 사용합니다.

Ingress는 "똑똑한 정문" 또는 리버스 프록시(reverse proxy) 역할을 합니다. 클러스터의 가장자리에 위치하여 들어오는 웹 트래픽을 살피고, URL을 읽은 다음 트래픽을 어떤 Service로 보낼지 결정합니다.

Minikube에서 이를 로컬로 설정하는 방법은 다음과 같습니다:

1단계: Ingress Controller 활성화

Ingress가 실제 라우팅을 수행하려면 컨트롤러(주로 NGINX)가 필요합니다. Minikube에는 이미 내장되어 있으므로 켜주기만 하면 됩니다:

minikube addons enable ingress

2단계: Ingress YAML 작성

ingress.yaml이라는 파일을 만듭니다. 이 파일은 Ingress 컨트롤러에게 다음과 같이 지시합니다: "누군가 루트 경로(/)로 들어오면, 80번 포트의 php-apache Service로 보내라."

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: php-apache
            port:
              number: 80

3단계: 적용하기

kubectl apply -f ingress.yaml

4단계: Minikube 터널 시작

Minikube는 노트북의 가상 머신이나 컨테이너 내부에서 실행 중이기 때문에, 노트북의 브라우저가 Ingress IP에 직접 도달할 수 없습니다. Minikube에게 그 간극을 연결해 달라고 요청해야 합니다.

새 터미널 창을 열고 다음을 실행하세요:

minikube tunnel

(참고: 로컬 네트워크 구성을 위해 컴퓨터의 관리자 비밀번호를 요구할 수 있습니다).

5단계: 앱 확인하기!

터널을 켜둔 상태로 유지하세요. 브라우저를 열고 다음 주소를 입력합니다: http://127.0.0.1

이제 브라우저가 Ingress 컨트롤러에 접근하고, 컨트롤러는 요청을 Service로 똑똑하게 라우팅하며, Service는 다시 자동 확장되는 파드들로 트래픽을 분산(로드 밸런싱)합니다!

이번에는 로컬에서 도메인을 설정해서 ip 없이 실행중인 pod의 어플리케이션을 가보겠습니다!

이 작업을 수행하려면 두 가지를 해야 합니다. 첫째, Kubernetes에게 이 특정 도메인 이름으로 들어오는 트래픽을 예상하라고 알려주어야 하고, 둘째, 컴퓨터가 해당 트래픽을 어디로 보내야 할지 알 수 있도록 숨겨진 로컬 "주소록"을 조작해야 합니다.

설정 방법은 다음과 같습니다.

1단계: Ingress 업데이트하기 (Kubernetes에 알려주기)

현재 여러분의 Ingress는 자신의 IP 주소로 들어오는 모든 트래픽을 잡도록 설정되어 있습니다. 실제 환경에서는 하나의 Ingress가 수십 개의 각기 다른 애플리케이션을 관리할 수도 있으므로, 요청된 특정 도메인 이름을 기준으로 트래픽을 라우팅하도록 가르쳐야 합니다.

이전 단계에서 작성한 ingress.yaml 파일을 열고 규칙(rule)에 host 줄을 추가합니다:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  rules:
  # 이 줄은 K8s에게 다음과 같이 지시합니다: "URL이 이 도메인과 일치할 때만 이 규칙을 적용하라!"
  - host: my-awesome-local-app.com 
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: php-apache
            port:
              number: 80

이 업데이트를 클러스터에 적용합니다:

kubectl apply -f ingress.yaml

2단계: `hosts` 파일 편집하기 (컴퓨터 속이기)

브라우저에 웹 주소를 입력할 때마다 컴퓨터는 그 이름을 IP 주소로 변환해야 합니다. 인터넷(DNS 서버)으로 나가서 길을 묻기 전에, 컴퓨터는 항상 hosts라는 숨겨진 로컬 텍스트 파일을 먼저 확인합니다.

여기에 가짜 항목을 추가함으로써, 요청이 인터넷으로 나가기 전에 가로채어 강제로 우리의 Minikube 터널(127.0.0.1)로 보내게 만듭니다.

Mac 또는 Linux 사용자인 경우:

터미널을 엽니다.
nano 텍스트 편집기를 사용하여 관리자 권한으로 파일을 엽니다: sudo nano /etc/hosts
컴퓨터 비밀번호를 입력합니다 (입력할 때 화면에 문자가 표시되지 않습니다).
화살표 키를 이용해 파일의 맨 아래로 이동한 다음, 정확히 다음 줄을 추가합니다: 127.0.0.1 my-awesome-local-app.com
저장하고 종료합니다: Ctrl+O를 누르고 Enter를 쳐서 확인한 뒤, Ctrl+X를 눌러 닫습니다.

Windows 사용자인 경우:

시작 버튼을 클릭하고 메모장(Notepad)을 검색합니다.
메모장을 우클릭하고 관리자 권한으로 실행을 선택합니다 (이 과정을 거치지 않으면 파일을 저장할 수 없으므로 매우 중요합니다).
메모장에서 파일 > 열기를 클릭합니다.
C:\Windows\System32\drivers\etc 폴더로 이동합니다.
파일이 보이도록 오른쪽 아래의 파일 형식 드롭다운 메뉴를 "텍스트 문서 (.txt)"에서 "모든 파일 (.*)"로 변경합니다.
hosts라는 이름의 파일을 엽니다.
파일의 맨 아래에 다음 줄을 추가합니다: 127.0.0.1 my-awesome-local-app.com
파일 > 저장을 클릭합니다.

3단계: 마법 경험하기

이제 모든 연결 고리가 완성되었습니다.

별도의 터미널 창에서 minikube tunnel 명령어가 여전히 실행 중인지 확인합니다.
웹 브라우저를 엽니다.
주소창에 http://my-awesome-local-app.com 을 입력하고 엔터를 칩니다.

컴퓨터는 도메인 이름을 보고 hosts 파일을 확인한 다음, 즉시 요청을 127.0.0.1로 라우팅합니다. Minikube 터널이 이를 잡아 Ingress로 전달합니다. Ingress는 "host" 헤더를 읽고 이것이 php-apache 규칙과 일치한다는 것을 알아차린 뒤, 여러분의 브라우저에 자동 확장되는 애플리케이션을 성공적으로 띄워 줍니다!

Kubernetes의 핵심 개념을 아주 정확하게 이해하셨습니다! 클러스터는 실제로 "컨트롤 플레인(Control Plane, 두뇌 역할)"이 여러 "워커 노드(Worker Nodes, 앱이 실행되는 실제 컴퓨터나 VM)"를 관리하는 포괄적인 시스템이 맞습니다.

하지만 Minikube가 무엇인지에 대해서는 약간의 오해가 있는 것 같습니다.

Minikube의 실제 역할

Minikube를 노트북을 위한 비행 시뮬레이터라고 생각해 보세요.

Minikube는 로컬 환경에서의 개발과 학습을 위해 특별히 설계된 가벼운 도구입니다. 이 도구는 오직 컴퓨터 한 대 안에서 작고 독립적인 Kubernetes 클러스터를 만들어냅니다. 노트북 안에 가상 머신이나 Docker 컨테이너를 생성한 뒤, 마치 그것들이 별도의 서버인 것처럼 "흉내"를 내는 방식으로 작동합니다.

여러 대의 Minikube를 서로 연결할 수 있나요?

아니요, 불가능합니다. Minikube는 완전히 격리된 로컬 샌드박스로 설계되었기 때문에, 컴퓨터 A와 컴퓨터 B에서 각각 Minikube를 실행한다고 해서 하나의 거대한 클러스터가 만들어지는 것이 아닙니다. 서로의 존재를 알지 못하는 완전히 분리되고 격리된 두 개의 미니 클러스터가 생길 뿐입니다.

여러 대의 컴퓨터를 실제로 연결하는 방법

네트워크 상에 2~3대의 물리적 컴퓨터(또는 별도의 VM)가 있고 이들을 연결하여 진짜 다중 노드(multi-node) Kubernetes 클러스터를 구성하고 싶다면, Minikube를 졸업하고 실무 환경을 위해 설계된 도구를 사용해야 합니다.

가장 인기 있는 방법들은 다음과 같습니다:

K3s (초보자 및 홈 랩 구축에 강력 추천): Rancher에서 만든 K3s는 매우 가볍고 표준을 완벽히 준수하는 Kubernetes 버전입니다. 불필요한 구형 클라우드 코드를 덜어내어 설치가 믿을 수 없을 만큼 쉽습니다. 컴퓨터 A에 명령어 하나를 실행하여 "Server(컨트롤 플레인)"를 설치하고, 컴퓨터 B에 또 다른 간단한 명령어를 실행하여 "Agent(워커 노드)"를 설치하면 A와 B가 연결됩니다. 안 쓰는 구형 노트북이나 라즈베리 파이(Raspberry Pi)에 사용하기 완벽합니다!
Kubeadm: 아무것도 없는 백지상태에서 Kubernetes 클러스터를 구축하는 공식적이고 전통적인 "정공법(hard way)"입니다. 전문가들이 기업의 데이터 센터에서 대규모의 고도로 맞춤화된 클러스터를 구축할 때 사용하는 방식입니다. 네트워킹과 보안 측면에서 훨씬 더 많은 수동 설정이 필요합니다.
관리형 클라우드 Kubernetes (EKS, GKE, AKS): AWS, Google Cloud, 또는 Azure를 사용한다면, 버튼 클릭 몇 번으로 클라우드 제공업체가 컨트롤 플레인을 대신 구축해 줍니다. 그런 다음 연결하고 싶은 가상 서버(노드)의 개수만 지정해 주면, 복잡한 네트워크 연결 작업은 클라우드 측에서 알아서 처리합니다.

references